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(54) Verfahren zur Unterstutzung der Interaktion zwischen einer ersten und einer zweiten Einheit 



(57) Zur Unterstutzung der Interaktion zwischen 
einer ersten Einheit, die gema& einer ersten Beschrei- 
bungssprachespezifiziert ist, und einer zweiten Einheit, 
die gemaG einer zweiten Beschreibungssprache spezi- 
fiziert ist, werden in beiden Einheiten jeweiis Klassen 
zur Verfugung gestellt werden, die die Bearbeitung von 
Typen steuern. In der ersten Einheit und/oder der zwei- 
ten Einheit werden hierbei ein oder mehrere hybrids 



Klassen zur Verfugung gestellt, die jewels sowohl die 
Bearbeitung eines gemaS der ersten Beschreibungs- 
sprache spezifiziertenTyps als auch die Bearbeitung 
eines, diesem Typ errtsprechenden, in einen Typen 
gemfiB der zweiten Beschreibungssprache konvertier- 
ten Typs steuern. 
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Beschreibung 

Die Erfindung betriffl ein Verfahren zur Unterstut- 
zung der Interaktion zwischen einer ersten Einheit, die 
gem&B einer ersten Beschreibungssprache spezifiziert 5 
ist. und einer zweiten Einheit, die gemSB einer zweiten 
Beschrefoungssprache spezifiziert ist, nach dem Ober- 
begriff von Anspruch 1, ein Verfahren zur Interaktion 
einer ersten Einheit, die gemaG einer ersten Beschrei- 
bungssprache spezifiziert ist, mrt einer zweiten Einheit, 10 
die gem&B einer zweiten Beschreibungssprache spezi- 
fiziert ist, nach dem Oberbegriff von Anspruch 5, ein 
Computersystem nach dem Oberbegriff von Anspruch 
7, eine Programm-Modul nach dem Oberbegriff von 
Anspruch 10 und eine Rechnereinhert nach dem Ober- 75 
begriff von Anspruch 11. 

Fur die softwaremdBige Realisierung von verteitten 
Computersystemen wird zunehmend die objektorien- 
tierte Modellierung als Arch'rtekturprtnzip verwendet. 

Eine solche Software - Architektur eines Computer- 20 
systems ist die CORBA • Architektur (CORBA = Com- 
mon Object Request Broker Architecture), die eine 
bedeutende Komponerrte der von der Object Manage- 
ment Group (OMG) spezifizierten OSA-Architektur 
(OSA = Object Service Architecture) ist. Objekte die 25 
dieser Spezrfikation fblgen, im folgenden CORBA- 
Objekte genannt, sind mittels der Beschreibungsspra- 
che CORBA IDL (IDL = interface definition language) 
spezifiziert. Auch sdmtliche Typen eines sdchen Objek- 
tes sind in dieser Sprache, also CORBA IDL, spezifi- 30 
ziert. 

Fur den Bereich des Netzwerkmanagements ist 
von der OSI (Open System Interconnection) ein Objekt- 
modell standardisiert (Management framework for open 
systems interconnection, ITU-T Recommendation 35 
X700, 1992). Seine Objekte, die im folgenden OSI- 
Objekte genannt werden, sind in der Beschreibungs- 
sprache ASN.1 (Abstract Syntax Notation) verwendet. 
Samtliche Typen eines solchen OSI-Objektes sind 
ebenfalis in dieser Sprache, also ASN.1 , spezifiziert 40 

Die Erfindung geht nun davon aus, wie die Bearbei- 
tung von Typen in einem Computersystem normaler- 
weise realisiert ist. FGr jede Typ steht normalerweise 
eine Klasse zur Verfugung, die die Bearbeitung dieses 
einen Typs steuert. 45 

Soil nun die Interaktion zwischen Objekte n, die in 
unterschiedlichen Beschreibungssprachen spezifiziert 
sind, ermOglicht werden, so treten Probleme auf: Die 
Typen sind in den Objekten auf unterschiedliche Weise 
spezifiziert, beispielsweise in ASN. 1 in OSI-Objekten so 
und in CORBA-IDL in CORBA Objekten. FQr.eine Inter- 
aktion sind deshatb Mechanismen erforderltch, die eine 
Typ-lnteroperabilrtat ermOglichen. 

Der Erfindung liegt nun die Aufgabe zugrunde, die 
Interaktion zwischen Objekten, die in unterschiedlichen ss 
Beschretoungssprachen spezifiziert sind, zu unterstQt- 
zen. 

Diese Aufgabe wird gel6st durch Verfahren nach 



der Lehre von Anspruch 1, und 5, durch ein Computer- 
system nach der Lehre von Anspruch 7, durch eine Pro- 
gramm-Modul nach der Lehre von Anspruch 10 und 
durch ein Rechnereinheit nach der Lehre von Anspruch 
11. 

Der Erfindung liegt hierbei der Gedanke zugrunde, 
daB hybride Wassen zur Verfugung gestelrt werden, die 
sowohl die Bearbeitung von Typen, die gemaB einer 
ersten Beschreibungssprache spezifiziert sind als auch 
die Bearbeitung der korrespondierenden Typen gemSB 
der zweiten Beschreibungssprache steuern. Mrttels 
einer solchen hybriden Klasse kOnnen so sowohl Typen 
die in der ersten Beschreibungssprache spezifiziert sind 
im Korrtext der zweiten Beschreibungssprache manipu- 
liert werden als auch umgekehrt 

Bei solchen Typen kann es sich vorzugsweise um 
Daten-Typen handeln. Bei Daten Typen handelt es sich 
um Kategorisierung von zu bearbeitenden Operations- 
Argumente, die typischer Weise beides enthalten, 
sowohl das Verhalten als auch die Darstellung. 

Eine Klasse ist ein abstrakter Daten-Typ, der ein 
Oder mehrere statische Oder dynamische Datentypen 
und Operationen, genannt ..methode", „verkapselT 
(encapsulate) also umschlieBt. Eine Klasse ist daruber- 
hinaus eine Implementierung, die Objekte (object 
instances), die dieser Objekt-KIasse angehdren und 
alle ein ahnliches Verhalten zeigen, erzeugen kann. 

Klassen spezrfizieren Objekte entsprechend einer 
allgemeinen Implementierung. 

Ein werterer Vorteil dieser Erfindung ist, daB sie 
schnelt ist, da Typdefinition und damrt die Abbildung vor 
Programmablauf berehs erfolgt ist. Es mussen keine 
Entscheidungen wahrend des Programmablauf, bei- 
spielsweise das Abprufen von Typen, durchgefuhrt wer- 
den. 

Besonders Vorteilhaft ist es hierbei, die Erfindung 
auf den Bereich des Netzwerkmanagement anzuwen- 
den, wenn dort sowohl OSI als auch CORBA-Einheiten 
vorhanden sind. Auf Grund des hohen MaBes an Inter- 
aktion, das in einer solchen Umgebung notwendig ist, 
ist hier die Anwendung der Erfindung besonders vorteil- 
haft. 

Im Folgenden wird die Erfindung anhand eines 
Ausfuhrungsbeispiels unter Zuhilfenahme beiliegender 
Zeichnungen beispielhaft erlautert: 

Rg. 1 zeigt eine Blockschattbild eines erfindungs- 
gemSBen Computersystems. 

Rg. 2a zeigt eine funktionelle Darstellung einer 
ersten M&glichkeit der Interaktion zwischen unter- 
schiedliche spezifizierten Objekten. 

Fig. 2b zeigt eine funktionelle Darstellung einer 
zweiten Mdglichkeit der Interaktion zwischen unter- 
schiedliche spezifizierten Objekten. 

Fig. 3a zeigt eine funktionelle Darstellung einer drrt- 
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ten MGglichkeit der Interaktion zwischen unter- 
schiedliche spezifizierlen Objekten. 

Fig. 3a zeigt eine funktionelle Darstellung einer 
vierten Mdglichkeit der interaktion zwischen unter- s 
schiedliche spezifizierlen Objekten. 

Fig. 4 zeigt eine logische Darstellung des Interope- 
rabilitats-Prinzips. 

10 

In dem Ausfuhrungsbeispiel wird cfie DurchfQhrung 
der erf indungsgemaBen Verfahren in einem erf indungs- 
gemaBen Computersystem beschrieben, das aus 
einem oder aus mehreren erfindungsgemafien Rech- 
nereinheiten besteht, auf denen jeweils ein oder meh- 75 
rere erf indungsgemaBes Programm-Modul ablaufen. 

Fig. 1 zeigt ein Computersystem CS mit drei Rech- 
nereinheiten C1 bis C3, die untereinander kommunizie- 
ren. 

Bei den Rechnereinheiten C1 bis C3 handelt es 20 
sich beispielsweise urn Computer, Drucker oder urn 
Netzelemente eines Kommunikationsnetzes. Sie wei- 
sen jeweils eine Hardware-Plattform, bestehend aus 
Prozessoren, Speichereinrichtungen und peripheren 
Komponenten, eine Software-Plattform, die beispiels- 25 
weise ein Betriebssystem und ein Datenbanksystem 
umfaBt und Anwendungen auf. die von auf der Soft- 
ware-Plattform ablaufenden Arrwendungs-Programm- 
Modulen gebildet werden. Die Rechnereinheiten CI bis 
C3 sind durch ein oder mehrere Kommunikationsnetze 30 
untereinander verbunden, beispielsweise durch X.25, 
#7, Ethernt Oder Token- Ring Kbmmunikationssysteme. 
Die Software-Plattform der Rechnereinheiten C1 bis C3 
stellt hierbei die notwendigen Datenubertragungsdien- 
ste bereit. 35 

Die Anwendungs-Programm-Module sind als 
Objekte (Managed objekt) modelliert d. h. der Code 
und die Daten eines Objektes werden durch eine 
Summe von Attributen und Funktionen reprasentiert, 
auf die andere Objekte zugreifen kOnnen. Durch das 40 
wechselseitige Zugreifen einer Vielzahl solcher Objekte 
werden sodann die Anwendungsfunktionen des Com- 
putersystems CS erbracht. 

Qemarl der CORBA-Architektur weisen die Rech- 
nereinheiten C1 bis C3 mehrere Objekte CO und SO 45 
und mehrere Objekt-Anforderungs-Broker (Object 
Request Broker) ORB auf. 

Aus der Dienstsicht k6nnen die Objekte CO und SO 
jeweils als eine verkapselte Einheit betrachtet werden, 
die einen oder mehrere Dienste zur Verfugung stellt, die so 
von einem Klienten (client) angefordert werden kfinnen. 
Die Objekte CO fordern hierbei Dienste an (Client 
Object), die von den Objekten SO erbracht werden 
(Server Objects). 

Zum Anfordern eines Dienstes sendet ein CO eine 55 
Anforderungs-Nachricht (request) an ein SO. Eine sol- 
che Anforderungs-Nachricht enthait hierbei folgende 
Informationen: eine Operation, ein Ziel-Objekt, keinen 



oder mehrere Parameter und optional einen Anforde- 
rungs-Kontext (request context). Nach Erbringen des 
Dienstes sendet das SO eine Ergebnis-Nachricht (out- 
come) an das CO zuruck, die fur diese Anfbrderungs- 
nachricht def iniert ist. 

Zum Senden und zum Empfang der Anforderungs- 
und Ergebnisnachrichten steht den Objekten SO und 
CO eine Schnittstelleneinheit IU zur Verfugung. 

Die Objekt-Anforderungs-Broker (ORB) stellen eine 
Infrastruktur zur Verfugung, die es den Objekten 
erlaubt, in einer verteiften Umgebung zu kommunizie- 
ren. Fur die Objekte CO ist es damit nicht von Bedeu- 
tung auf welchem der anderen der Rechnereinheiten 
C1 bis C3 ein Objekt SO, dessen Dienst sie anfordern 
wollen, angesiedelt ist und auf welcher spezieilen Piatt- 
form oder in welchem ImplementierungsverfahYen das 
Objekt realisiert ist. 

Jedes Objekt kennt hierzu zumindest einen Objekt- 
Anforderungs-Broker ORB und weiB, wie sie diesen 
lokalen Objekt-Anforderungs-Broker zu kontaktieren 
hat. Jeder Objekt-Anforderungs-Broker weiB wie er 
andere Objekt-Anforderungs-Broker kontaktieren kann 
und wie er mit ihnen zu kommunizieren hat. Hierfur Ver- 
wendet er das RPC-Verfahren (RPC = remote proce- 
dure call mechanisms). Ein Objekt sendet somit eine 
Anforderungsnachricht und einen der Objekt-Anforde- 
rungs-Broker ORB. die Weiterreichen der Anforde- 
rungsnachricht an das Ziel-Objekt wird durch die von 
den Objekt-Anforderungs-Broker ORB gebildeten 
CORBA-lnfrastruktur erledigt. 

Urn uber die CORBA-lnfrastruktur mittels CORBA- 
Mechanismen interagieren zu kOnnen und mit anderen 
Objekten auf dieser Infrastruktur zusammenarbeiten zu 
kOnnen, muB jede der Objekte CO und SO Ober eine 
CORBA spezifische Schnittstelle (Interface) verfugen. 
Ein solche Schnittstelle enthait hierbei eine Beschrei- 
bung eines Satzes von mOglichen Operation, die eine 
anderes Objekt von diesem Objekt anfordern kann. Die 
Schnittstellen der Objekte sind hierbei in der Beschrei- 
bungssprache IDL (Interlace Definition Language) defi- 
niert, bei der es sich um eine reine Schniffstellen- 
Beschreibungssprach handelt. Die Vererbung (inheri- 
tance) dieser Interfaces erlaubt esdaB ein Objekt meh- 
rere Schnittstellen unterstutzt. 
I 

In CORBA wird auf ein Objekt direkt Ober diese 
CORBA spezifische Schnittstelle zugegriffen. Die 
Implementierung cfieser Schnittstelle ist das Object 
selbst. Es besteht aus Code und Daten und benfitigt 
somit keine Ausfuhrungsinstanz (Agent entity), wie dies 
der Fall ist, wenn ein Objekt rein durch eine Datenstruk- 
tur reprasentiert ist. 

Das Computersystem enthait nun neben den 
Objekten CO und SO weitere Objekt. die nicht in Fig. 1 
gezeigt sind. Diese sind nicht in CORBA spezrf iziert und 
interagieren uber spezielle Schnittstelleneinherten uber 
die oben beschriebene. CORBA-lnfrastruktur unterein- 
ander und mit den Objekten CO und SO interagieren. 
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Die Verwendung solcher hybrider Komponenten 
auf einer CORBA-lnfrastruktur hat hierbei den Vorteil, 
daB bereits bestehende, gemaB einer anderen Objekt- 
Modell Architektur spezifizierte Objekte wiederverwen- 
det werden kGnnen und eine Zusammenarbeit solcher 
Objekte mit CORBA Objekten ermfiglicht wird. Dies hat 
vor allem im Bereich des Netzwerkmanagement groBe 
Vorteile, da in diesem Bereich bereits eine Vielzahl von 
Objekten bestehen, die gemaB des OSI-Objektmodells 
spezifiziert sind. OSI-Netzwerkmanagent-Komponen- 
ten, beispielsweise Manager, Agent, Mediation Device, 
werden jeweils von einem oder mehreren solche OSI- 
Objekte gebildet. 

FOr den Bereich des Netzwerkmanagements ist 
von der OSI (Open System Interconnection) an Objekt- 
modell standardisiert (Management framework for open 
systems interconnection, ITU-T Recommendation 
X.700, 1992). Neben dem Objektmodell (SMI = Struc- 
ture of Management Information) sind auch grundle- 
gende Objekte, ein Set von Management Diensten 
(CM IS common management information service defi- 
nition) und ein Netzwerkmanagement-Protokoll (CMIP 
= Common Management Information Protocol) zur 
Kommunikation der Objekte untereinander spezifiziert. 
Objekte sind in der Beschreibungssprache GEMO spe- 
zifiziert, die ASN Syntax verwendet und weitere eigene 
Makros enthait 

Der Prinzipielle Unterschied zwischen w naturlichen" 
CORBA-Objekten und w naturlichen M OSI-Objekten 
besteht darin, daB die CORBA Objekte die Implemen- 
tierung der CORBA-Schnittstelle darstellen, wohinge- 
gen die OSI-Objekte eines Netzwerkmanagement- 
selements als Datenstruktur im MIB-Datensatz (Mana- 
gement Information Base) abgelegt sind und durch 
einen Agenten, mit dem mittels des CEMIP-Protokolls 
kommuniziert wird, manipuliert werden. Daruberhinaus 
sind ihre Datentypen in unterschiedlichen Beschrei- 
bungssprachen spezifiziert, nSmlich in CORBA IDL und 
in ASN.1 und damit nicht kompattoel. 

In Fig. 2a, Fig. 2b, Fig. 3a und Fig. 3b sind nun 
mOgliche Implementierungen von OSI Einheiten' auf 
einer CORBA Infrastruktur und gleichzeitig Mogliche 
Arten der Interaktion zwischen CORBA Einheiten und 
OSI Einheiten uber eine CORBA Infrastruktur aufge- 
zeigt Die MGglichkeit der Interaktion Qber eine CORBA 
Infrastruktur impliziert hierbei solch eine Interaktion zwi- 
schen Einheiten in unterschiedlicher Spezrfizierungs- 
sprache. Es erfordert der gleiche Vorgehensweise. Als 
Einheit wird hierbei ein Gebilde mit einem oder mehre- 
ren Objekten betrachtet. 

Rg. 2a zeigt eine Kommunikationsschicht 
CORB/ORB, mehrere uber diese Kommunikations- 
schicht allgemein zur Verfugung stehende Dienste 
CMISE Services, zwei Netzwerkmanagement-Kbmpo- 
nenten M und A und jeweils zwei zwischen diesen 
Objekten und der Kommunikationsschicht CORB/ORB 
gelegenen Kommunikationsfunktionen GMO/C++ und 
CMISE/IDL 



Bei den Komponenten M und A handelte es sich 
nicht urn CORBA-Objekte, sondern jeweils urn ein oder 
mehrere OSI- Objekten OM bzw. OA und einer Mana- 
ger bzw. Agent Funktionseinheit. Jeder der Komonen- 

5 ten M und A stellt somit eine OSI Einheit dar. Mittels der 
Agent bzw. Manger Funktionseinheit werden Operatio- 
nen auf diesen Objekten ausgefuhrt bzw. Anforderung 
an andere Objekte versendet. Agent und Manager 
Funktionseinheit kommunizieren uber das CMIP-Proto- 

10 toll. Aus der Sichtweise des Netzwerkmanagement 
nimmt die Komponente M die Rolle eines Managers 
(Manager) und die Komponente A die eines Agenten 
(Agent) ein. 

Die Kommuniktationseinheit GDMO/C++ besteht 

75 aus einem oder mehreren speziellen Zugriffs-Objekten, 
die die Ausfuhrung von CMISE Operationen auf den 
Objekt OA oder OM erm6glichen. 

Die CMISE Management Dienste werden durch ein 
CMISE-Objekt auf der Seite des Objektes OA realisiert. 

so Die Schnittstelleneinheit CMISE/IDL enthSIt dieses 
CMISE-Objekt und die cfiesem Objekt zugeordneten 
Dienste. Das CMISE-Objekt der Schnittstelleneinheit 
CMISE/IDL ist durch ein IDL-lnterface spezifiziert ist 
und agiert und erscheint so nach auBen wie ein 

25 CORBA-Objekt. Urn diese Spezifizierung und damit die 
Bereitstellung einer CORBA-Schnittstelle zu dem 
Objekt OA zu ermdglichen, ist eine Typkonvertierung 
Oder Typ-lnteroperabiletat von ASN.1 in IDL Typen not- 
wendig. Wie diese Type-lnteroperabilitat erreicht wird, 

30 wird spater anhand von Fig. 4 dargestellt CMISE-Dien- 
ste stellen somit als ein Set von CORBA Objekten zur 
Verfugung. Durch Qber die CORBA-infrastruktur geleitet 
CORBA-Anforderung kOnnen so CMISE-Operationen 
auf dem Objekt OA ausgefuhrt werden. Gleiches gilt fur 

35 das Objekt MO. 

Eine zweite Mdglichkeit der Anbindung von OSI- 
Einherten Qber eine CORBA-lnfrastruktur ist in Fig. 2b 
aufgezeigt 

Rg. 2b zeigt die Kommunikationsschicht 

40 CORB/ORB, mehrere uber diese Kommunikations- 
schicht allgemein zur Verfugung stehende Dienste 
CMISE Services, die Objekte OM und OA und jeweils 
zwei zwischen diesen Objekten und der Kommunikati- 
onsschicht CORB/ORB gelegenen Kommunikations- 

45 funktionen GDMO/IDL und CMISE/IDL 

Durch die Schnittstelleneinheit GDMO/IDL werden 
die in GDMO spezifizierten OSI-Objekte der Kompo- 
nenten A und M in eine Spezifikaton als IDL Schnitt- 
stelle Qbersetzt Auf ein so spezifiziertes Objekt kann 

so durch Wassische CORBA-Nachrichten zugegriffen wer- 
den. Jedes dieser OSI-Objekt wird somit in ein reines 
CORBA Objekt transformiert. Da die Spezifikation in 
IDL und ASN.1 von unterschiedlicher Natur sind 
(Schnittstellenbeschreibung <- > Objekt-Spezifikation) ist 

55 keine vollkommene Ubersetzung mOglich und nur ein 
Untermenge von CMISE-Diensten wird uber die 
Schnittstelleneinheit GDMO/IDL angeboten. Dies 
bedeute, daB nur eine Untermenge von CMISE Opera- 
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tionen auf den transformierten CORBA-Objekten aus- 
fuhrbar ist. 

In Fig. 3a und Fig. 3b sind weitere M6glichkeiten 
der Interaktion zwischen Netzwerkmanagement-Kbm- 
ponenten dargestellt wobei hier ein Gateway GATE eirv 
gebunden wird. Die genaue Funktionsweise ergibt sich 
aus der Darstellung in den Figuren 3a und 3b zusam- 
men mil der Beschreibung der korrespondieren Einhei- 
ten, die bereits in der Beschreibung zu den Figuren 2a 
und 2b gemacht wurde. 

Die Typinteroperabilrtat wird nun wie folgt erreicht : 

Typen im ISO Kontext sind in der Beschreibungs- 
sprache ASN.1 und Typen im CORBA Kontext in in 
der Beschreibungssprache IDLdefiniert. Die erfor- 
derliche Unterstutzung fur dies Typen in jedem 
Kontext muR gesteuert werden. Diese Unterstutzen 
ist jeweils in Klassen implementiert, sowohl in 
CORBA Einheiten als auch in OSI Einheiten. Als 
Klassen werden hierbei folgende gewahrt: 

• Die Klassen, die die Unterstutzung der Typen 
in der Beschreibungssprache IDL in CORBA 
Einheiten bereitstellen. Diese Klassen werden 
im folgenden HdlG Klassen genannt. Hierbei ist 
anzumerken, daB normalerweise eine Klasse 
fur einen Typ zustandig ist. 

• Die Klassen, die die Unterstutzung der Typen 
in der Beschreibungssprache ASN.1 in OSt 
Einheiten bereitstellen. Diese Klassen werden 
im folgenden AsnG Klassen genannt. 

Das Vorgehensweise ist zweigeteilt. Dies wird im 
Folgenden anhand eines Sender/ Empf&nger Paars 
aufgezeigt: 

Urn die Behandlung von IdIG Typen in einer OSI 
Einheit zu unterstotzen, wird der korrespondie- 
rende AsnG Typ aus dem IdIG Typ konstruiert. Hier- 
fur wird ein .constructor", also ein Steuerelement 
zum erzeugen eines Programm-Objekts zu der 
Klasse hinzugefugt, die den AsnG Typ unterstutzt 
Dieser „construdor ,t nimmt eine IdIG Typen als 
Parameter. Dadurch unterstutzt diese AsnG Klasse 
auch die Bearbeitung des korrespondierenden IdIG 
Typs. 

Urn die Verwendung von AsnG Typen in einer 
CORBA Einheit zu ermfiglichen, wird der AsnG Typ in 
den korrespondierenden IdIG Typen transformiert. Dies 
wird dadurch erreicht, daB eine neue Funktion zu der 
Klasse hinzugefugt wird, die diesen AsnG Typen unter- 
stutzt. Diese Funktion nimmt den AsnG Typen als Para- 
meter und giebt den korrespondierenden IdIG Typen 
zuruck. 

Fig. 4 zeigt nun eine logische Darstellung dieses 
Interoperabilitats-Prinzips : 



Fig. 4 zeigt die Einheit SEM und die Klasse CLASS. 
Die Einheit SEM stellt die gesammte Semantik, den 
Inhalt eines Objektes. dar. Ein Teil davon ist die Klasse 
CLASS, die Syntaxbeschreibungen behandert. Diese 

5 Klasse CLASS empfangt Typen unterschiedlicher Syn- 
tax, Typen in der Beschreibungssprache IDL und 
ASN.1. Sie liefert unterststutzung fur die korrspondie- 
rende unterschiedliche Typen IdIG und AsnG. Die 
Unterstutzung der IdIG Typen wird hierbei wie oben 

w beschrieben bereitgestellt, indem uber einen „constru- 
cor" IdIG Typen erzeugt und uber ein Funktion AsnG 
Typen in IdIG Typen konvertiert werden. 
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Patentanspruche 



1. Verfahren zur Unterstutzung der Interaktion zwi- 
schen einer ersten Einheit, die gemaB einer ersten 
Beschreibungssprache spezrfiziert ist, und einer 
zweiten Einheit, die gemaB einer zweiten Beschrei- 

20 bungssprache spezrfiziert ist, wobei den beiden 
Einheiten jeweils Klassen zur Verfugung gestellt 
werden, die die Bearbeitung von Typen steuern, 
dadurch gekennzeichnet, daB der ersten Einheit 
und/oder der zwerten Einheit ein oder mehrere 

25 hybride Klassen zur Verfugung gestellt werden, die 
jeweils sowohl die Bearbeitung eines gemaB der 
ersten Beschreibungssprache spezifizierten Typs 
als auch die Bearbeitung eines, diesem Typ ent- 
sprechenden, in einen Typen gemaB der zweiten 

30 Beschreibungssprache konvertierten Typs steuern. 

2. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, daB als erste Spezifizierungssprache fur die 
Spezrfizierung von Typen ASN.1 verwendet wird. 



3. Verfahren nach Anspruch 1 , dadurch gekennzeich- 
net, daB als zweite Spezifizierungssprache fur die 
Spezrfizierung von Typen CORBA- IDL verwendet 
wird. 



4. Verfahren nach Anspruch 1 , dadurch gekennzeich- 
net, daB die hybride Klasse Oder die hybriden Klas- 
sen ein Konvertierung zwischen Typen gemaB der 
ersten Beschreibungssprache und Typen gemSB 

45 der zweiten Beschreibungssprache durchfOhren. 

5. Verfahren zur Interaktion einer ersten Einheit, die 
gemaB einer ersten Beschreibungssprache spezrfi- 
ziert ist, mit einer zweiten Einheit, die gemaB einer 

so zweiten Beschreibungssprache spezifiziert ist, 
wobei der ersten Einheiten Klassen zur Verfugung 
gestellt werden, die die Bearbeitung von Typen 
steuern, 

dadurch gekennzeichnet, daB der ersten Einheit 
55 ein oder mehrere hybride Klassen zur Verfugung 
gestellt werden, die jeweils sowoN die Bearbeitung 
eines gemaB der ersten Beschreibungssprache 
spezifizierten Typs als auch die Bearbeitung eines, 
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diesem Typ entsprechenden, in einen Typen 
gemaB der zweiten Beschreibungssprache konver- 
tierten Typs steuern. 

6. Verfahren nach Anspruch 5, dadurch gekennzeich- s 
net, da(3 die erste Einheit von zumindest einem 
Objekt gebildet wird und daB die hybride Klasse 
Oder eine der hybriden Klassen im Interface dieses 
Objektes angeboten wird. 

10 

7. Computersystem mit mindestens einer ersten Ein- 
heit, die gemaB einer ersten Beschreibungsspra- 
che spezifiziert ist und mrt mindestens einer 
zweiten Einheit, die gemaB einer zweiten Beschrei- 
bungssprache spezifiziert ist, wobei den beiden is 
Einheiten jeweils Klassen zur VerfQgung stehen, 

die die Bearbeitung von Typen steuern, 
dadurch gekennzeichnet, daB der ersten Einheit 
und/oder der zweiten Einheit ein oder mehrere 
hybride Klassen zur Verfugung stehen, die so aus- 20 
gestaftet sind, daB sie jeweils sowohl die Bearbei- 
tung eines gemaB der ersten Beschreibungs- 
sprache spezrfizierten Typs als auch die Bearbei- 
tung eines, diesem Typ entsprechenden, in einen 
Typen gemaB der zweiten Beschreibungssprache 25 
konverterten Typs steuern. 

8. Verfahren nach Anspruch 7, dadurch gekennzeich- 
net, daB die erste Einheit eine OSI-Einheit ist. 

30 

9. Verfahren nach Anspruch 7, dadurch gekennzeich- 
net, daB die zweite Einheit eine CORBA-Einheit ist. 

10. Programm-Modul, das gemaB einer ersten 
Beschreibungssprache spezifiziert ist und in dem 35 
ein oder mehrere Klassen zur Verfugung stehen, 

die die Bearbeitung von Typen steuern, 
dadurch gekennzeichnet, daB in dem Programm- 
Modul ein oder mehrere hybride Klassen zur Verfu- 
gung stehen, die so ausgestaltet sind, daB sie 40 
jeweils sowohl die Bearbeitung eines gemaB der 
ersten Beschreibungssprache spezrfizierten Typs 
als auch die Bearbeitung eines, diesem Typ ent- 
sprechenden, in einen Typen gemaB der zweiten 
Beschreibungssprache konvertierten Typs steuern. 45 

11. Rechnereinheit auf der ein Programm-Modul nach 
Anspruch 10 abiauft. 
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